method AND APPARATUS FOR PROVIDING WEB 

semobsk fXcoEwwnw comput.ng system 

Field of the Invention 
,01] This invention relates to peer-to-peer collaborative computing systems 
and to methods and apparatus for providing web sea-ices in such a 
environment to allow the collaborative system to be accessed from other app„ca,ons 

and platforms. 

Background of the Invention 
[021 Collaboration involves the ability for each member in a group of members, 
caned "collaborators" to automatically transmit information to, and receive informal 
Tom other coHaborafors in the group. In order to facilitate such collaborate venous 
Jems have been deveioped that a„ow such information to be transmitted etween 
personal computer systems, communication appliances or other communicabon 
devices, including handheld and wireless devices. Collect, these devrces w,„ be 
referred to a "computers" in this description. 

,03] Computer-based collaboration may occur over a network, such as the 
,nterne wherein each of the users is located at a computer connected to the network, 
teral'coiiaboration models are currently being implemented as ft**. «r 
coloration systems. One ofthese models is a "peer-to-peer" mode ,n wh,ch d.rect 
connections are established over the network between each of the 
computers. Information generated by each collaborator is then sent d.rectly to each 
other collaborator. In such a system, the collaborators communicate in a pnvate 
^"shared space. Thus, in such systems, each collaborator has a local copy o, fhe 
data being collaboratively modified. In order to change the data, a 
generates a data change request that is forwarded to each ofher collaborator. T e 
incoming data change requests are then used by each coHaborator to mod,fy ,ts local 

data copy. 
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COMMUNICATIONS MANAGER, fled J* * ^ serial no. 

Moore, Robert H. Myhill and Brian M. Lambert, 

COLLABORATION BY A COMPUTER SYSTEM EQUIPPED Wl 

MANAGER, flied July 19, 1999 by ^^^^S FOR 

™ non^R 148 entitled METHOD AND APKAKA uo 
applicatfon senal no. WfiWtftt MAINTAINING DATA 

PRiORITIZING DATA CHANGE REQUESTS A FOR 
CONSISTENCY IN A DISTRIBUTED COMPUTER SYSTEM ^ 
ACTIVITY-BASED COLLABORATION, Hied July "^^M M£TH0D AND 
jack E. Ozzie and U.S. patent applicalion senal no ffled June 6 , 

2000 by Raymond E. Ozzie, i\enueu. 

Fischer ' tem nmvides a complete interactive environment 

msi Such a collaboration system provides a corny 

program resident on his or her oomputer. «"£L*L ~«« " "» 

oollaboralive system 1o other applications, env,ronmen,s and platforms. 
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SUMMARY OF THE INVENTION 



OUW1IVIMFM V. 

I061 in accordance w*h the principles olthe invention, common interfaces 
! Zn API development framework to provide a standard way to 
provided from an open API developm , nt fram ework uses 

access, process, and store collaborate data ~ as S0AP , 

standard Web Senrices technologies, protocols and me.hodolog.es. 



30 WSDL and HTTP. 
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k Himpnt the API development framework uses a Simple 
m |„ one embod.me t, the API de P ^ 

in web Services. This protocol allows any end-pen. on » gnd 

. bridge betwe en the native ool^at ^1^— can be 
or application ,ha. can proces SOAP com. ^ 
either local (on the same machine as the j|lustrative 
re mote (on a different machine). In addit,on to the WSA ^ 
framework includes client side support that is compnsed of a SOAP pro y 

(ne collaborative system (SSTP). The collaborate c, en, recess ,h 
the context of a standard collaborative tool compone, 

server. 

, component is then called and a result returned to the SOAP 

brief Description of the drawings 

m The above and further advantages of the invention nray be better 
undeiod by referrin g «o *e following description in conjunct with ft. 

• a ^r~r:r— ^^^^ 

SySte ;rnl y 2 Ta e b,oc k sche m atic diagram o, a de-coupled system operating in 



[«] Figure 3 is a flowchart that shows the steps in an illustrative process for 
Drocessing a SOAP request using the system of Figure 2. 

' M4 Figure 4 is a block schematic diagram of a de-coupled system operaflng ,n 
asynchronous mode and constructed in accordance with the principles of the 



an 

invention 
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[15] Figure 5 is a flowchart that shows the steps in an illustrative process for 
orocessing a SOAP request using the system of Figure 4. 

' Z Figure 6 is a block schematic diagram of an integrated system operat, g ,n 
a sync ro ous mode and construct in accordance with the principles of the inven Jon. 

[17] Figure 7 is a flowchart tha, shows the steps in an illustrate process for 
nmrp^ina a SOAP request using the system of Figure 6. 

P T 8 Figl 8 is a block schema* diagram of an integrated system operaflng ,n 
asynchronous mode and constructed in accordance with the principles of the 



an 



invention. 



[191 Figure 9 is a flowchart that shows the steps in an illustrative process for 
Drocessinq a SOAP request using the system of Figure 8. 

P0] Figure 10 is a block schematic diagram o, an integrated system operaflng 

to nrovide event notification services. 

[21] Figure 11 is a block schematic diagram showing the SOAP mterfaces and 
20 SOAP engine in an exemplary collaborative client. 

[221 Figure 12 is a flowchart illustrating the steps in an illustrate process for 
processing SOAP requests in a collaborative client wflh a SOAP proxy component. 

Detailed Description 
[23] Figure 1 illustrates, in a very schematic form, a pee,1o-peer collaboration 
system 100 in which collaborating computers are connected to each other by a ne^ork 
08 such as the Internet. Although various networks can be used wflh such a system, 
rdlssion below, the nelwork 108 is assumed to be the Intern. = ,n, 
th e collaborating computer systems constitute peer units, of wh,c , unfl 02 ^and 04 
3 „ are shown, and communications through the Interne, 108 can be d.rected from one peer 
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a persona, computer or other form o, nelworK-capable dev.ce, such a a se *pb« « 
hand-held device. The collaborative system is implemented on peer unft 102 and 104 

•«* e^ceivesandp^sses—afions 

fr0m °;:rre:^ercommunica,ionscan te 

For exam le, peer unit 102 may communicate direcfiy with peer unit 104, as indicated 
c ematically by dotted ft* 110. However, a relay uni. 106 is provided to temporary 
"muLLsthata^ 

connected to the network 108. Thus, relay senrer 106 acts as a store and taw* 
ler I. peer unit 102 sends communications to peer unit 104 when peer un, 104 ,s 

2 these communicalions ,o relay senrer 106 which holds .he 
^ unit 104 is again connected «o network 108. When peer uni. 104 connects .o 
network 108, rt notifies relay server 106 which then sends all lemporanly stored 
communication to it as indicated by arrow 114. 

,25] in one embodiment each collaborative user has a unique user queue w,.h 
the re, y server 106. Collaborative c,ien.s attach .o .heir user queues to receive venous 
messages (,nc,uding da.a change commends, «en«1y messages, e.c) desfined to 
L and end messages desfined to olher coilaborelive clienls to .he user queues tor 
lose ciienfs (in .he case when fine direc. communicefion between .he coliabomfive 

clients is impossible). Qn prific 
[26] Queues may also be provided for other purposes. A queue for a pe ,fic 
purpose is uniquely defined wifh a Inpie o, (IdenfityURL, DeviceURL, ^ourceURLV 
, The resource URL par. resides the ,y P e o, messages with which .he queue deais. For 
example, there is a unique resource URL for IdenlityMessage, end .here ,s un,que 
resource URL for data change messages. 

,27] A collaboration system such as that shown in Figure 1 is eve„eb,e from 
Groove Nelworks, Inc., 100 Cummings Center, Suite 535a Bevedy. M — etts 
o 0191 5 and is described in detail in the Groove™ Platform Development K,t wh.ch ,s 



available from Groove Networks, Inc. and on-line on http://www.groove.ne,. n the 
discussion below, the collaboration system will be assumed to be such a system 

could also be used with the present invention. 

P8] in this collaboration system, a program called an "activity" ,s resrden. ,n 
each collaborating computer system, communication appliance or other «*o* 
capable device. The activity allows a shared, focused task, such as for ex ampte a 
"chat" gaming, or business application, to be performed in collaborate with other, 
I Xloca ed collaborators. This collaboration involves shared and mutual aCvrtes 
ZZ individuals and small groups in private shared spaces. Bach shared space ,s 
an instantiation of one or more aotivkies operable on each of the collaborating 

computers of members of that shared space. 

.291 In the system, participants or members of a shared space access the 

system by opening "accounts" that are associated with "endpoints." Sine* an in— 
Ibol may access .he system via more than one device, an endpo,nt ,s defined 
as a unique combination of an individual and a device. Each endpo.n, stores an 
individual, local copy of the shared space data. 

[30 ] Each activity includes one or more tools, each of which interacts wtth a 
collaborator, for example, by receiving mouse and keyboard events, and inittates data 
change requests in response to the interactions. These data change request are used 
oca! y and sent to other members of the shared space. Each activity also includes n 
lore data-change engines, separate fiom the tools, for maintaining the loca copy of 
the shared space data pursuant to a common data model. The data mode, ,s for 
example, activity-specific, and preferably the same over a„ members of the shared 
, space Each elaborating computer also includes a dynam,c S manager, that examines 

data change requests generated locally and received from other shared space 
members and coordinates the execution of the loca, and other data change requests 



data. 
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[31] In accordance with the principles of the invention, one or more of the peer 
units, such as units 102 and 104, is modified to include SOAP interfaces (discussed in 
detail below.) With these interfaces, collaborative access methods are exposed in 
standard SOAP format so that other platforms can use the SOAP language to 
communicate and interact with this collaborative client and to extract collaborative data. 

[32] This SOAP service provides an integration point where other systems can 
integrate with the collaborative system. For example, a portal service could be based 
on a centralized database server. With an integrated system based on the SOAP 
protocol, it would be possible for the users to use this portal to not only access 
centralized data from the database, but also to access data from the collaborative 
system itself. 

[33] The modified peer units can also be connected, via a WSAP server, to 
other applications and environments that do not use the peer unit client software, but 
can act as collaborative clients. As mentioned above, a WSAP server makes it possible 
for these new clients to access information within the collaborative system on a wide 
variety of computing environments. 

[34] The WSAP server serves as a translation and relay point for the 
communication between an external SOAP client and a particular collaborative client. 
To this end it includes a special SOAP client queue that has a unique resource URL 
(such as, grooveSOAP://RPC;Version=1, 0,0,0) for soap requests and responses and a 
unique resource URL (grooveSOAP://Event;Version=1 ,0,0,0) for events. The server 
makes it possible for two parties to communicate with each other, regardless of the 
existence of firewalls between them. The SOAP interfaces allow external SOAP clients 
to access a SOAP engine in that collaborative client and the SOAP engine supports the 
remote client interfaces. It is also possible to directly access to a collaborative client's 
SOAP engine, for example with cross-process local RPC calls. 

[35] The WSAP server is designed so that it can be configured either as an 
independent server entity, separated from relay servers, or as coexisting with a relay 
server. In its independent (de-coupled) mode, a WSAP server acts just as a translation 
(for protocol) relay agent. Based on the information carried in the SOAP header, the 

7 



server forwards the actual request to the relay server for the recipient. By using an 
existing relay server as the point for communicating with the collaborative client, the 
server can take advantage of the existing relationship between the collaborative cheat 
and relay queues and the existing storage management that queues provide. Th,s 
reduces the programming requirement for the communication between the server and 
the collaborative client. In its integrated mode, the server can deal with the relay queue 
infrastructure directly. In both cases, the server hosts the result message by proving 
queue management functionality. 

[36] As shown in Figure 2, in order to make a SOAP request, a SOAP cl.ent 
200 sends a SOAP message to the WSAP server 210. Every SOAP message is 
contained in a SOAP envelope that has a header section and a body section. In 
accordance with standard SOAP protocol, the header section is optional, but the body 
part must be present. In the illustrative system, SOAP requests use both the header 
and body sections. Any information that must be conveyed to the server 210 is placed 
in the header section, while any information that is to be conveyed to the collaborate 
client 208 is placed in the body section. 

[37] All SOAP calls use a SOAP "fault" to carry any error status. That is, if a 
response envelope is not a SOAP fault, it indicates a success, and data should be 
included, if there is any. In a SOAP fault, the "faultcode" value is set to "Client" or 
"Server A "Clienf fault indicates that the fault is related to a bad request. In this case, 
the caller should reformat the request and try again. A "Server fault indicates that there 
is problem processing the request body. A "detail" section may be present to carry a 
"GrooveFault" section for more specific information. 

[38] A fault can be generated by the server 210, or by the SOAP engine in the 
collaborative client. In the latter case, if the SOAP engine generates any exception or 
error, it will format a SOAP Fault envelope and return the message to the sender s 
queue. 

[39] The server 210 can return either "Clienf or "Server fault. "Client" faults 
are generated when necessary fields in the SOAP envelope are missing. The server 
21 0 can return a "Server fault of "GESGWTTLEXPIRED" if the time to live established 
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synchronously or asynchronously. The use of relay 

no th«t Pxoect real responses will carry a Time-To-Live ( M lj 
message calls a e ec - p ^ ^ ^ ^ 

indicating how long the server response. Thus, 

th ere is one round trip .0 send a request an get a espo ^ 
,„« HTTP response for the request does not carry the actual respo 

SOAP client must make another call *° J^^p 1 ^^^^ serv er 210 will modify the 
[411 To support a synchronous SOAP request, tn - 12as80ciate d 
■ , , C1 that the response will return to a unique queue 212 assoaateo 
„ senders dev,ce ^"^wL* 210 has forwarded the moditled SOAP request 
with that sender. After the WSAP s 212 for the 

envelope to the relay server 204, the server wa GESGWTTLE XPIRED fault 

res ponse. If the time-lo-live expires, the server ""T'J^^^ 

20 retrieve the response again from the queue 

SOAP request as generated by the SOAP client 200: 

<s:Envelope ....> 

<s:Header> » h ttn-//webservices.groove.net/Groove/1.0/Core/ > 

<TimeToLive>20</TlmeToLive> 
</g:GrooveHeader> 
</s:Header> 

30 < ^d y> X mlns---ht,p://we b servioes.groove.ne VG roove/,0/ S pacesr/> 

</s:Body> 
</s:Envelope> 



„ The fo,.owing shows the request as received by the cC.aborative system 
indicating the fields added by the server: 

<s:Envelope ....> 
5 < S: a oteHeaderx m lns--»h«p://webse™ioe = 

</RemoteClientDeviceURL> n et</GatewayURL> 

" ^^^^^^^^^ 

</GrooveldentityURL> 
<GrooveClientDeviceURL>dpp.^ 

<TimeToLive>20</TlmeToLive> 

<ZmeSwS/G ro ove/1.0/Spaces/</docu m ent> 

20 </HTTPHeaders> 
</s:Header> 

<S <S™lns=W~^^ 
</s:Body> 
25 </s:Envelope> 

(43, The following shows the format for a response when the fime-fo-live has 
expired: 

30 <s:Envelope ...> 
<s:Body> 

<s'Fault> 

,itrnHp>sServer</faultcode> 
tSng>GESGWTTLEXPIRED</faults.nng> 

35 ^SooveFauKxrnlns-^ 

</g:GrooveFault> 

40 </detail> 
</s:Fault> 
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</s:Body> 
</s:Envelope> 



from synchronous 

M For an asynchronous - <^ " the setve r 210 has forwarded the 
calls because the method name ends w,th _a ), e ^ ^ 

piggyb acK the actual response T ^ ^ t0 reWeve the 

Read(), with one or more message IDs return 

SOAP request. A typical SOAP header embod iment, this 

w-senthac^^ 

-echo" section is used to carry a un.q .. Rea uestlD" field can be used to 

carry this unique identification. 
SOAP request: 
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<s:Envelope ....> n/r^rp/"> 
<S:Heade M M derxmlns=»h tt p://webservices.groove.net/G^ 

<TimeToLive>20</TlmeToL.ve> 
</g:GrooveHeader> 

</Echo> 
</s:Header> 

^axm,ns=W.//webse,lces,roove.ne U Oroove,,0,Spaces//> 

</s:Body> 
</s:Envelope> 
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nature of the call: 

</Read_aResponse> 

10 </s:Body> 
</s:Envelope> 

from the server in asynchronous mode. 
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25 



30 



<s:Envelope ... > n(rnror> 
<S ? eade M M derxmlns="http://webservices.groove.net/Groove/1.^^^^ 

<TimeToLive>20</TlmeToL.ve> 
</g:GrooveHeader> 
</s:Header> 

<s-Body> , .„ ae nronve net/Groove/1 .0/Messages/ > 

</Read> 
</s:Body> 

</sEnvelope> . . 

from the collaborative client: 



<s:Envelope ...> 
<s:Header> 

35 1 R e° q uestlD>1234567890abcd</RequestlD> 
</Echo> 

40 Slponsex.— we bS e„;c e , gro ov,neVO ro ove,1.0,Spacesr> 

12 
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.... (real data comes here) 
</ReadResponse> 

</s:Body> 

</s:Envelope> ra „„p^ ID in that section 

1491 ,tisa,so :::* o"^^—^^^^ 

The following is an example of a !>u« 

can tnat fells to get response bacK due to t,me out 

<s:Envelope ....> 
<s:Body> 
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</detail> 
</s:Fault> 
</s:Body> 
25 </s:Envelope> 
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the caller fo fry again fo retrieve «h* response ^ ^ ^ 

[50] If a request carnes an Echo sec ^ ^ 

section to the envelope header part, so fhaUhe c* 
previous request. The following is an example of 



<s:Envelope ...-> 
35 <s:Header> 

lRequestlD>f234567890abcd</RequestlD> 

</Echo> 

13 



</s:Header> 
<s:Body> 



</g:GrooveFault> 

10 </detail> 
</s:Fault> 
</s:Body> 
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<,S:EnVe '° Pe> , rie dicated thread handles the polling of result 

n W^asynohronous.^ a^ed ^ toretum 

result (a huge value or -1 TTL value • 

p2) ,„ synchronous mode . ts ,mp ^ ^ „ ^ ^ 

a ttu value comes back indicating the m has -p ^ ^ ^ ^ ^ ^ po „ 
again using the specific returned message _ ^ ^ 

*e right queue (the one specif, for toaUeg -JJ g WSAp sewer 210 

W 2 * 3 at M - sv^ tonous mode. As shown in Figure 2, a 

in a de-coupled system and operating , a syn ^ ^ m yia , 

SOAP client 200 uses a WSAP serve 21 to a SQAp 

service interfaces, and acceptmg SOAP q ^ ^ re , ay s[orage 

tne relay server program code ease, bu ^ ^ 

,„ management to handle SOAP response queues an 

user queues. steps in a n illustrative synchronous 

pA] Figure 3 is a flowchart that shows , t P ^ ^ pfocess 

process by which the SOAP client ^'It ^llabo^e 0^,208 that wants 
begins in step 300 and proceeds to step 302 where a 
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_ roo „ ters . -convenient" name with the name 
to expose it, remote client interface rasters a c ^ 

schematically by arrow 220. The conve regis tration time, the 

be associated with the service mat is be,ng exported «* . 9 ^ 
coliaboralive Cient 208 associates •£^^ -BB (de vice URL, 
infor ma«on about the user (identty URL^user d ^ ^ ^ 

optional), user, relay information (re* URL, ^ ^ fc 

those who want to use SOAP interface te | ep hone call, etc. 

p. Later, as set to* ,n slep 306^ SOA ^ by ^ 

, he WSAP server 210 by send.ng a SOAP me , ^ ^ ^ 

216 . Since the WSAP server 210 ****** • « ^ 214 10 

Cient 208 so that it can perform a name loo^p ,n ^ ^ ^ ^ 



20 "wtest" 
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, xm , ns . s oAP-ENV=-ht.p://schemas.xmlsoap.o^soap/enveloper 
<SOAP-ENV:Envelope xmlns.buar en 
<SOAP-ENV:Header> , (httn . //webservice s.groove.net/Groove/1 .0/Core/ > 

<TimeToLive>30</TimeToLive> 
^ /r5rrtr>\/oHfiader> 



</GrooveHeader> 
</SOAP-ENV:Header> 
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.,«^ad CM\/-Rndv> 



</SOAP-ENV:Body: 
</SOAP-ENV:Envelope> 
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chap reauest the WSAP server first 

checks the HTTP header element o f Oonten :Tf, ^ ^ 

regular SOAP envelope or this is a DIME message. In ^ 
D ME message to extract the SOAP envelope. Then ^^"J^. ^ 
see whether » Is a valid XML document and ^ server 210 

tailure will cause a SOAP fault to be sen. back to he «n£ ^ 

, *u uttp POST URI to determine what service uiis> m 
.hen checKs the HTTP POST U ^ & ^ ^ 

requests for serv,ces that the serve P and ^ (he 

response wrth the HTTP respon ^ name of 

208. the WSAP server checks the SOAP header a ^ 
.he collaborative client 208. U then performs a name ooku ^ 
database 214 as indicated schematical. by arrow m ^ ^ ^ 

the ac cess information (user identity URL - m and tne client 
„ collaborative client 208. This information ,denbf,ea the relay 

rrr^rrrr.'::-' 

20 header information, along with its URI value (obtained from the 

grooveDNSy/webservicest .groove.net), the HTT URL into 

HTTP/HTTPS header) and a unique message ID as the ,w ^ 

, Tho WSAP server URL identifies the WbAr serve 
.he SOAP header. ^ J engine in the collaborative den. can send .he 
incoming request to that the SOAP eng ^ ^ ^ ^ sQAp engjne 

26 response back to the same .serve, ™* , & Jhen lhe se rver 

to determine the serv,ce and me*od ^ [f ft fe ^ 
checks whether i. is in .he relay for .he t0 send the 

modified SOAP request (in rts complete SOAP P 



16 



ooa The SSTP protocol is described in detail 
204 as indicated schematically by arrow 224. The SSTP 
ln th e aforementioned Groove Platform Developers SOK ^ ^ 

[59] ,n step 312. the relay sender 204 pfcces to _ J ^ ^ ^ 

recipient's relay then the modrfed SOAP request q 
recipienVsqueue206as,his — 

oollaborativa client 208 will be asynchronous as welt ^ 
once the modified request is en-queued into the rec,p q 

JirniJl-requ^headeras 
15 server 210 will generate a un,que message ID a ^ ^ ^ 

the caileris "device" URL. This information, ^ ^ header) , 

user identity URL (both inserted by the server 210 into the 

1621 l l byarrow226,and P rocesses,hereques,. Instep 

20 request from rts queue 206 (mdrcated by , nforma tion, including 

316, client 208 Inen extracts from the request the sender co ^ _ 

- — se ™r uru r: r^^s « — - soap 
« l63] — -•--r-rzrrrr^ 
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„ no response is ready before - eviration, the response - J£« ~ 

„ 2 t de lues the response envelope and returns i. as the response for 

result queue 212, it dequeues in v The process then finishes in step 

the original SOAP request as indicated by arrow 218. The proce 

W2 ,66! Figure 4 is a block schematic diagram that illustrates a WSAP server 410 

to SOAP client 400. As shown in F.gure 4, a SOAP client 

V h>h thP SOAP client 400 accesses the collaborat.ve cl.ent data. Th.s 

user (identity URL), user's device information (device URL, opfional), users relay 
user ^laeniuy ^ owner of the 

information (relay URL), among other mformafion. In step WM 
oollaborative client 408 then disseminates th,s convemen. name to 
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us e SOAP interface to reach this collaborate client. The name is provided using an 
^-band" method, « ^J^J^ such as client 400, maKes a 

appears ,n the header. Anot P is ^ . nc|u(jed as 

request header is the aforementioned TTL value. An 

" diSCUS :Sr; e e f o,low,n g isane X am P leo f anas y nchronousre q uestmessa g e«hatis 

^tfjialredspacesatthecollahorative client, usin g a convenient name o, 

'West": 

, , vmin,SOAP-ENV=' 1 http://schema S .xmlsoap.org/soap/envelope/"= 
15 <sOAP-ENV:Envelope xmlns.SOAP tiMv .my 

<SOAP-ENV:Header> 
<G^ 

<TimeToLive>30</TimeToLive> 



c^rooveiaiy^"- "- . 

<TimeToLive>30</TimeToLive> 

</GrooveHeader> 
</SOAP-ENV:Header> 



25 iSX^ebser^ 



</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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N0 ,e that the method (Read_a) is idenfified by an >" ««£ 

the "echo" section that contains a unique identification in the RequestID secfio. Th,s 
:;;:ltJfion will later be returned Intheresponseandisusedtocorrelatea 
response with a previous request as explained below. 
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chap rpauest the server checks the SOAP 
[701 In step 508, upon receiving a SOAP request, in 

performs a name lookup with the name «^ {user , dentrty 

bya rrow430. »*^*^2Sir*-i» This 
URL, relay URL, and optional devrce URL) for he c 
information identifies the relay server 404 and the cl,ent queue 

Cnen, 4 ° 8 ' . the server 410 modifies the SOAP request so that the 

[71] m step 510, the servers Forexamp | e , the server 410 inserts 

resp onse will return to the SOAP olien. que* ,412. new 
the result of ,he name lookup in database 4 ,n«o the OAR requ ^ 
h eader information, along with its own URL (ServerfJR and *e ^ 

•ii th* rplav 404 serving the recipient, 
server/relay w,ll be the relay 8 ef 410 retums a response 

l73] For asynchronous SOAP requests. ^ ^ 

25 collaborative client queue 406, or has sue y 

recipient's relay server 404. This ,s set for. , step ^ 

whi ch could be a SOAP -fault" as discussed abov. do s earry ^ $ 

clienfs response but only carrfes the unique messe* ° ^ » not. The aclual 

zrr-*=rr="-— 



30 
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The following is an example of a response for an asynchronous SOAP request 
indicating that a SOAP request (Read_a for spaces) has been en-queued: 

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> 

<SOAP-ENV:Body> 
<Read_aResponse xmlns=http://webservices.groove.net/Groove/1 .0/Spaces/ > 
<MessagelD>4312180bf57041318f10b9e8d48e81b3</MessagelD> 

</Read_aResponse> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

In this response, no actual status is returned, as the return of a normal SOAP 
envelope indicates a success. If any error occurs, a SOAP Fault will be returned. 

[74] As indicated in step 51 6, the collaborative client 408 eventually reads the 
request from its queue 406 (indicated by arrow 426) and processes the request. In step 
518, client 408 then extracts from the request the sender contact information, including 
the sender's server URL, identity URL and the generated device URL. Such 
information, along with a fixed (well-known) resource URL for SOAP processing, 
uniquely identifies the SOAP client queue 412 on the server 402. In step 520, the 
collaborative client 408 sends the result, in a SOAP response envelope format, to the 
server 410 for the SOAP client 400, by putting the result into the SOAP client queue (as 
indicated schematically by arrow 422.) 

[75] In asynchronous mode, the SOAP client 400 is responsible to poll the 
WSAP server 410 for any responses using a message services Read() call as set forth 
in step 522. The response to the Read() call will be in a SOAP response envelope and, 
if a response has been returned from the collaborative client 408, the response to the 
Read() call will be the SOAP response received from the collaborative client 408. If a 
response has not been received from the collaborative client 208, then the Read() call 
response will be a SOAP fault message indicating that there was no response available 
before the TTL expired. It is important to note that no assumption can be made 
concerning the order in which the SOAP responses are returned. Therefore, the caller 
is responsible for correlating a response with a previous request. This correlation is 
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performed with an "echo" section in the SOAP header that carries a unique 
identification. In one embodiment, this unique identification is carried in the RequestID 
section of the SOAP header. This echo section is returned with the response and can 
be used to correlate the response with a previous request. 

[76] The following is an example of a Read() call that can be issued by the 
SOAP client 400 and that attempts to poll for a response: 



<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> 

<SOAP-ENV:Header> 
10 <GrooveHeader xmlns="http://webservices.groove.net/Groove/1 .0/Core/"> 
<GrooveTargetName>wtest</GrooveTargetName> 
<TimeToLive>999999</TimeToLive> 
</GrooveHeader> 
</SOAP-ENV:Header> 

15 <SOAP-ENV:Body> 

<Read xmlns="http://webservices.groove.net/Groove/1.0/Messages/"> 

<Messagel D>431 2 1 80bf57041 3 1 8f 1 0b9e8d48e81 b3</Messagel D> 

</Read> 

</SOAP-ENV:Body> 
20 </SOAP-ENV:Envelope> 

In this example, the call will tell the server 410 to wait at the response queue 412 
for the given SOAP client (with its target name and message ID) and return only when it 
has read a response message, or return empty after 999999 seconds. 
25 [77] The WSAP server 410 then returns a response, as set forth in step 524, if 

either a response has been received from the collaborative client 408 or the TTL has 
expired. The following is an example of a response to Read() call with no response: 

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> 

30 <s:Body> 
<s:Fault> 
<faultcode>s:Server</faultcode> 
<faultstring>GESGWTTLEXPIRED</faultstring> 

<detail> 

35 <g:GrooveFault xmlns:g="http://webservices.groove.net/Groove/1 .0/Core/"> 

<errorreason>gateway returns after time-to-live expires</errorreason> 
<MessagelD>ecsf83va8aesiwetkdjgfg2z3pucvqeh</MessagelD> 
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</g:GrooveFault> 
</detail> 
</s:Fault> 
</s:Body> 
</s:Envelope> 

[78] The following is an example of a response to Read() call that returns with 
a response from the collaborative client 408 to the aforementioned Read_a() request: 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"> 
<soap:Header> 
<Echo xmlns=http://tempuri/> 
<RequestlD>j5e77spwsea42nrksfg2mxknwq966fnafai63is</RequestlD> 

</Echo> 
</soap:Header> 
<soap:Body> 

<Read_aResponse xmlns="http://webservices.groove.net/Groove/1 .0/Spaces/"> 
<ReadResult xmlns="http://webservices.groove.net/Groove/1.0/Spaces/"> 
<Space> 

<URI>grooveTelespace://skw3cuyxya4d8kwnqxm47bftci6ih97puzdjet2</URI> 

<Name>test2</Name> 

<Description>My Test Space</Description> 

<Created>2002-1 2-02T1 1 :28:40.025-05:00</Created> 

<Modified>2002-12-04T16:32:50.795-05:00</Modified> 

<Local>true</Local> 

<ldentityURL>grooveldentity://w78jcypifdvbi9e893tt92a3dc72nssd@</ldentityURL> 

<Tools>/GWS/Groove/1 .0/Tools/ 

grooveTelespace/skw3cuyxya4d8kwnqxm47bftci6ih97puzdjet2</Tools> 

<Members> 

<URI>grooveldentity://j3dwkub9gxxqpi6zuhjhvb7hiryfmycw@</URI> 
<URI>grooveldentity://w78jcypifdvbi9e893tt92a3dc72nssd@</URI> 

</Members> 
</Space> 
<ReadResult> 
</Read_aResponse> 
</soap:Body> 
</soap:Envelope> 

Note the return of the "echo" section in the SOAP header that is used to correlate 
this response with a previous request. The process then finishes in step 524. 
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[79] In the integrated mode, the WSAP server code is also built on top of the 
relay server code, and provides the functions of a normal relay server. Figure 6 is a 
block schematic diagram that shows a WSAP server in an integrated system and 
operating in a synchronous mode. In this figure, it is assumed that the WSAP 

5 server/relay 606 is also the relay server used by the collaborative client 616. 

[80] Figure 7 is a flowchart that shows the steps in an illustrative synchronous 
process by which the SOAP client 600 accesses the collaborative client data. This 
process begins in step 700 and proceeds to step 702 where a collaborative client 616 
that wants to expose its remote client interface registers a convenient name with the 

10 name service database in associated with the WSAP server 606. This operation is 
illustrated schematically by arrow 610. At the registration time, the collaborative client 
616 associates this name with a number of name-value pairs, with information about the 
user (identity URL), user's device information (device URL, optional), user's relay 
information (relay URL), among other information. In step 704, the owner of the 

1 5 collaborative client 61 6 then disseminates this convenient name to those who want to 
use the SOAP interface to reach this collaborative client. The name is provided using 
an "out-of-band" method, such as e-mail, telephone call, etc. 

[81] Later, as set forth in step 706, a SOAP client, such as client 600, makes a 
SOAP request to the server 606 by sending a SOAP message as indicated 

20 schematically by arrow 602. Since the server 606 must obtain the convenient name of 
the collaborative client 616 so that it can perform a name lookup in the name service 
database 608 to find the access information for the collaborative client 616, this name 
appears in the header. Another piece of information that is usually included with the 
request header is the aforementioned TTL value. 

25 [82] In step 708, upon receiving a SOAP request, the server 606 checks the 

SOAP header and extracts the convenient name of the collaborative client 61 6. It then 
performs a name lookup with the name service database 608. It also checks the 
availability of the access information (user identity URL, relay URL, and optional device 
URL) for the collaborative client 616. This information identifies the client queue 612 for 

30 this collaborative client 616. 



[83] In step 710, the server 606 modifies the SOAP request so that the 
response will return to the SOAP client queue 614. For example, the server 606 inserts 
into the SOAP header, as new header information, the result of the name lookup in 
database 608, the HTTP POST URI value (from the HTTP header) and a unique 
message ID, which is generated by the server 606 and serves as the source client 
"device" URL. The server 606 then places the request in the recipient's queue 612 as 
indicated schematically by arrow 618. 

[84] Once the modified request is en-queued into the recipient's queue 612, 
the server 606 waits for a response to return to a queue 614 for the calling SOAP client 
600. As indicated in step 712, the collaborative client 616 eventually reads the request 
from its queue 612 (indicated by arrow 622) and processes the request. In step 714, 
client 616 then extracts from the request the sender contact information, including the 
sender's server URL, identity URL and device URL (unique message ID.) Such 
information, along with a fixed (well-known) resource URL for SOAP processing, 
uniquely identifies the SOAP client queue 614 on the server/relay server 606. In step 
716, the collaborative client 616 sends the result, in a SOAP response envelope format, 
to the server 606, by putting the result into the SOAP client queue 614 (as indicated 
schematically by arrow 624.) 

[85] The server 606, after placing the SOAP request in the recipient's queue 
612, will wait on the result queue 614 as indicated by arrow 620. If a response is ready 
before the TTL expires, It is returned as-is as the SOAP response for the original SOAP 
request. If no response is ready before the expiration, the response is a SOAP fault 
message that contains the indication that there is no response available. In that case, 
the fault message will carry the message ID used for this call, so that if desired, the 
SOAP client can call a message services Read() method with the specific message ID 
to poll the response again. 

[86] In step 71 8, when the server 606 notices the new arrival of the data in the 
result queue 614, it de-queues the response envelope and returns it as the response for 
the original SOAP request as indicated by arrow 604. The process then finishes in step 
720. 
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[87] Figure 8 is a block schematic diagram that illustrates a WSAP server 806 
in an integrated system and operating in an asynchronous mode. This system operates 
in a manner very similar to the synchronous mode described in connection with Figures 
6 and 7. Thus, in Figure 8, elements that correspond to elements in Figure 6 have been 

5 given corresponding numeral designations. For example, SOAP client 600 corresponds 
to SOAP client 800. As shown in Figure 8, a SOAP client 800 uses a WSAP 
server/relay 806 to access a collaborative client 816. 

[88] Figure 9 is a flowchart that shows the steps in an illustrative asynchronous 
process by which the SOAP client 800 accesses the collaborative client data. This 

1 o process begins in step 900 and proceeds to step 902 where a collaborative client 81 6 
that wants to expose its remote client interface registers a convenient name with the 
name service database in associated with the WSAP server/relay 806. This operation 
is illustrated schematically by arrow 810. In step 904, the owner of the collaborative 
client 816 then disseminates this convenient name to those who want to use SOAP 

1 5 interface to reach this collaborative client 81 6. 

[89] Later, as set forth in step 906, a SOAP client, such as client 800, makes a 
SOAP request to the server 806 by sending a SOAP message as indicated 
schematically by arrow 802. 

[90] In step 908, upon receiving a SOAP request, the server 806 checks the 

20 SOAP header and extracts the convenient name of the collaborative client 81 6. It then 
performs a name lookup with the name service database 808. It also checks the 
availability of the access information (user identity URL, relay URL, and optional device 
URL) for the collaborative client 816. This information identifies client queue 812 for this 

collaborative client 816. 
25 [91] in step 910, the server 806 modifies the SOAP request so that the 

response will return to the SOAP client queue 814. For example, the server 806 inserts 
into the SOAP header, as new header information, the result of the name lookup in 
database 808 into the SOAP request as the new header information, the HTTP POST 
URI value (from the HTTP header) and a unique message ID that it generates and that 
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represents the source client "device" URL. Then the server 806 enqueues the modified 
SOAP request into the recipient's queue 812. 

In step 912, the server 806 returns a response (indicated schematically by arrow 
804 after it has successfully put the request into the collaborative client queue 812. As 

5 discussed above, this response does not carry the collaborative client's response, but 
only indicates whether the above operation is successful or not. 

[92] As indicated in step 914, the collaborative client 81 6 eventually reads the 
request from its queue 812 (indicated by arrow 822) and processes the request. In step 
916, client 816 then extracts from the request the sender contact information, including 

10 the sender's server URL, identity URL and device URL (unique message ID.) Such 
information, along with a fixed (well-known) resource URL for SOAP processing, 
uniquely identifies the SOAP client queue 814 on the server 806. In step 918, the 
collaborative client 816 sends the result, in a SOAP response envelope format, to the 
server 806 by putting the result into the SOAP client queue 814 (as indicated 

15 schematically by arrow 824.) 

[93] The SOAP client 800 then polls the WSAP server 806 for any responses 
using a Read() call as discussed above and as set forth in step 920. The process then 
finishes in step 922. 

[94] Using a remote client interface, a collaborative client can also support the 
20 notification of certain events, such as when a new entry has added to the Discussion 
Tool, or when a new file has added to a Files tool. A SOAP client can specify the kind 
of events in which it is interested and receive notification of these events from the 
collaborative client by subscribing to these events. 

[95] Figure 10 is a block schematic diagram that illustrates the notification 
25 process. To subscribe to an event, the SOAP client 1000 sends a request, through the 
server 1006, to the collaborative client 1014, specifying a source in which it is interested 
and a callback URL indicating the location to which the events should be sent. The 
SOAP client 1000 receives a unique subscription ID, which it can use later to renew and 
delete this subscription. 
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[96] To retrieve events, the SOAP client 1 000 uses an events service call, 
passing in the callback URL provided during the aforementioned subscription process 
as indicated schematically by arrow 1002. The server 1006 then checks the 
corresponding queue 1008 and waits if no messages are available as indicated 
schematically by arrow 1010. When an action that is subject to notification happens in 
the collaborative client 1014, the client 1014 generates an event and sends the event to 
the server 1006 using the callback URL specified in the subscription as indicated 
schematically by arrow 1012. The server 1006 will then put the event into the SOAP 
client queue 1008. When the server 1006 finds a new message in the queue, it de- 
queues the message and returns the message to the SOAP client 1000 as indicated by 
arrow 1004. The message can either be a response to a previous request or an event. 
The SOAP client 1000 can distinguish the event messages because an event message 
does not correlate with any previous request message. 

[97] Figure 1 1 is a block schematic diagram showing the internal construction 
of a SOAP engine 1 102 on an illustrative collaborative client 1 100. The SOAP engine 
includes a SOAP proxy component 1 104, a subscription manager 1 106 and various 
services 1 108-1 114. The SOAP engine 1 102 registers with a communication manager 
and indicates an interest in all data sent to aforementioned client queue in the WSAP 
server or relay server. In this manner, when the communication manager de-queues 
any data from this queue, the data, in the form of a SOAP envelope, is passed to the 
SOAP engine 1 102 for processing. 

[98] The SOAP proxy component 1 104 is a component that translates SOAP 
RPC requests into method invocations on a target COM interface. The component 
1 104 is initialized with the system services on the collaborative client, and listens for 
incoming HTTP communications. Figure 12 is a flowchart that illustrates the steps in 
servicing an incoming SOAP request. This process starts in step 1200 and proceeds to 
step 1202 where the SOAP proxy component 1 104 reads the header from the SOAP 
request. Next, in step 1204, the SOAP proxy component determines the service being 
invoked and, in step 1206, the proxy component determines the target object from the 
header. 

28 



[99] Then, in step 1 208, the proxy component instantiates the service and 
optionally calls methods on the service if it implements certain interfaces, to determine 
more detailed context about the method. In step 1210, the proxy component translates 
all inbound parameters from a SOAP representation to a COM (VARIANT) 
representation. In order to handle custom data types, the services being called must 
implement data serializers. This interface is installed at initialization time of the service. 
A serializer must implement two methods: 

Serialize(IUnknown* i_pValue, IGrooveWebServicesSerializationlnfo*); 

and 

Deserialize(IGrooveWebServicesSerializationlnfo*, I Unknown** o_ppValue); 

[100] The IGrooveEdgeWebServicesSerializationlnfo argument allows a 
serializer to describe the contents of its data using name-value pairs. This is done 
independently of any format used to transmit the data over the network. The 
serialization information is written to and from SOAP using IGrooveSOAPReader and 
IGrooveSOAPWriter methods. This separation allows the network transmission format 
to change without requiring a change in the serialization code. 

[101] When the SOAP proxy component 1 104 encounters a data type, by 
reading type library information, it will first attempt to translate it to an intrinsic data type, 
such as an "integer" or "string." However, if the data type is a user defined type, a type 
library will be used to identity the GUID, or interface ID of the type. A sub-component 
called a type mapper maintains a map from GUID to serializer interface and calls the 
serializer to serialize or de-serialize the data to and from SOAP. 

[102] Next, in step 1212, the selected service processes the data and generates 
a response. In step 1214, the proxy component translates any return value back to a 
SOAP response envelope. The return value is serialized the same way that the request 
was serialized. A SOAPWriter method transforms the serialization information into the 
SOAP response section of the SOAP envelope. In step 1216, the SOAP proxy 
component then enqueues the data to a remote device URL corresponding to the SOAP 
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client relay server or passes the envelope back to the local SOAP server, depending on 
the origin of the original request. 

[103] In particular, the SOAP engine 1 102, after processing the request, returns 
the result, in a SOAP response envelope, to a specific queue owned by the SOAP 
client. This queue, as any other queues, is defined with a triple: {IdentityURL, 
DeviceURL, ResourceURL}. The engine 1 102 obtains such information from the 
original SOAP request, as its header contains the needed information, including the 
server URL. The resource URL is the same SOAP specific one (a well-known one for 
the server and the collaborative client). The process then finishes in step 1218. 

[104] Eleven services are illustrated. These include the accounts service 1 108, 
the calendar service 1110, the contacts service 1112, the discussion service 1114, the 
events service 1 1 16 the files (base 64) service 1118, the files (DIME) service 1 120, the 
messages service 1 122, the spaces service 1 124, the tools service 1 126 and the 
transceiver service 1 128. Each service implements supports up to four methods, 
including Create(), Read(), Update() and Delete() methods. The Read() method 
retrieves a record or list of records. The Create() method creates a new record. The 
UpdateO method modifies an existing record and the Delete() method deletes an 
existing record. Each method is responsible for updating or returning collaborative data. 
In addition, services may provide similar methods that operate on data items managed 
by the sen/ice. 

[105] The accounts service 1 108 provides information about all the accounts on 
the local collaborative device and is a starting point for a hierarchical access to all web 
services available on the device. It supports a Read() method that provides information 
about all collaborative accounts on the device. For security reasons, this service is only 
available from a local web service client. 

[1 06] The calendar service 1110 provides information about the events in a 
collaborative calendar tool and enables a SOAP client to create new events and delete 
or modify existing events. It supports Create() and Read() methods that create and 
read entries in the calendar tool. When the Read() method is used, it returns the data in 
each entry and the URI of that entry. In addition, this service supports ReadEntry(), 
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UpdateEntryO and DeleteEntryO methods that read, modify and delete calendar entries 
identified by a URI. 

[107] The contacts service 1112 provides information about the collaborative 
contacts stored for an identity. It supports a Read() method that returns information 
about all contacts associated with an identity, including contacts from shared spaces 

and any personal contact lists. 

[108] The discussion service 1114 provides information about the entries in a 
discussion tool and enables a SOAP client to create new entries and delete or modify 
existing entries. It supports Create() and Read() methods that create and read entries 
in the discussion tool. When the Read() method is used, it returns the data in each 
entry and the URI of that entry. In addition, this service supports ReadEntry(), 
UpdateEntryO and DeleteEntryO methods that read, modify and delete discussion 

entries identified by a URI. 

[109] The events service 1116 provides a mechanism for SOAP clients to 
retrieve web services events. The subscriptions service (discussed below) creates and 
manages a queue for the events. If the SOAP client is local, the collaborative client 
queues events as they are emitted from the underlying tool. However, if the SOAP 
client is remote, then the collaborative client sends the events to the subscription 
service as they are emitted and the subscription service queues the events. The events 
service supports a Read() method that reads events from SOAP client subscriptions 
and returns an array of events. If the SOAP client is local, then the service returns an 
array of events that includes all events that have been emitted since a previous Read() 
method call. Alternatively, if the SOAP client is remote, the SOAP proxy component 
returns only one event in an array for each Read() method call. Therefore, the remote 
SOAP client must call the Read() method repeatedly until no more events are returned. 

[1 1 0] The files (base 64) service 1118 provides information about files in a files 
tool and enables a SOAP client to read the contents of a file, create a new file, and 
delete or modify an existing file. This service uses Base64 to encode the file contents. 
The service supports Create(), Read() and Delete() methods that create a file or folder 
with specified descriptors and contents and read files and directories. When the Read() 
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method is used, it returns the data in each file and the URI of that file. In addition, this 
service supports ReadFile() and UpdateFile() methods that read the files and modify the 
content and name of files identified by a URI. 

[111] The files (DIME) service 1120 operates in the same manner and supports 
the same methods as the files (Base64) service 1118, with the exception that it uses the 
SOAP DIME protocol to transfer the file contents. 

[112] The messages service 1 122 provides a mechanism for remote SOAP 
clients to retrieve messages sent by the collaborative client but not received by the 
SOAP client because the time-to-live had expired. This service supports the 
aforementioned Read() method uses by remote SOAP clients to retrieve the messages. 
It is provided by the SOAP proxy component and is not available to local SOAP clients. 

[113] The spaces service 1 124 provides information about shared spaces 
owned by a specified identity. It supports a Read() method. 

[114] The tools service 1 126 provides information about the tools in a shared 
space via a Read() method. 

[115] The transceiver service 1 128 allows an external application to open a 
workspace window on the local device and direct the user to a specified URL or enables 
the user to send an instant message or shared space invitation. It can only be used by 
a local SOAP client and supports three specialized methods. These include 
SendlnstantMessage() the opens a window to send an instant message to a specified 
identity; Sendlnvitation() that opens a window to invite the specified identity to a shared 
space and View() that opens a window to display a specified tool to a specified identity. 

[116] The V-card service 1 130 provides additional information about an identity, 
which information would typically be found in a v-card, such as an e-mail address and 
full name. This service supports a Read() method. 

[117] The subscription manager 1106 implements a subscription service that 
allows a remote endpoint to subscribe to any supported data model to receive 
notifications. The subscription service has an API that includes three methods: 
Create(), Delete() and Update(). The Create() method creates a new subscription to 
events emitted by the specified web service. When a remote client wants to subscribe 
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to events, it must provide four parameters. The first parameter is called the event class 
and is a string that is used by a service designer to identify an event class that it will 
support. An example is "urn:groove.net:DiscussionToolEvent." The second parameter 
is an event source URL. This is usually a bindable URL to the component that will fire 
the event. The third parameter is a callback URL, which is a URL that identifies the 
recipient of the event. The callback URL allows the system to implement event 
notification using different URL schemes, such as mailto:, http:, ftp, and dpp. The last 
parameter is a time to live value that allows subscribers to specify the number of days 
that the subscription should last. The service returns a subscription ID that can be used 
to renew, or unsubscribe from the event source. The Delete() method deletes a 
subscription and the Update() method renews the subscription for a specified time to 
live. 

[118] Internally, the subscription manager 1 1 06 maps an event type to a 
"subscriber factory." The subscriber factory is a COM interface implemented by a 
service. When a subscription is created, the subscription manager uses the subscriber 
factory to create a "subscriber." The subscriber represents the actual connection from 
the data model object to an event handler internal to the service that uses COM 
connection points to receive the notification from the data model object. 

[119] When a subscriber gets a notification it informs the subscription manager 
using a serialized format of the event data, and the subscription manager, in turn, uses 
protocol handlers to dispatch the event to the appropriate remote endpoint. Subscribers 
can be activated and deactivated when needed. 

[120] The subscription manager implements interfaces for creating and 
renewing subscriptions, and for sending out event data. An 
IGrooveEdgeServicesSubscriptionContext interface contains information about the 
subscription: the event type, the subscription ID, the source URL and its containing 
objects (Tool, Telespace, and Account). An IGrooveEdgeServicesSubscriberFactory 
interface creates subscribers based on event type. An IGrooveEdgeServicesSubscriber 
interface, when activated, uses the subscription context to bind to the data model and 
its connection point container interface to connect for internal events. It also uses an 
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IGrooveEdgeServicesSerializationlnfo interface to forward the event data to the 

subscription manager. 

[121] For local SOAP usage, a local name service 1132 is provided. This 
service will allow a user to register an alias for a supported data model object and 
5 functions identically to the name service discussed above, but without any server 
dependencies so that local client(s) can work in the off-line mode. It will also provide a 
way to register local names with the aforementioned name service. 

[122] When a collaborative client decides to register a name, it registers the 
name with the name service, as described above and with the local name service. A 
io name can be registered with the local name service only (where this name will only be 
resolved locally). A name registered with the name service will also be registered with 
the local name service as well. The latter practice ensures the support of direct access 
to the collaborative client from a remote client without going through any server, which 
may act to resolve the name with its name service. In the direct case, the collaborative 
1 5 client uses the local name service to resolve the name, thus working without the 
dependency of an online name service server. 

[123] To register a name with either the name service or the local name service, 
the user creates an XML file containing a request to add a user name and the values to 
which it corresponds. The XML file may also contain a request to remove a user name. 
20 The following is an example of such an XML file: 



<GNSRequests> 

<AddGNSNames> 
<UserName> 

<GNSName> 

Usernamel 
</GNSName> 
<GNSNameSpace> 

SOAP 
</GNSNameSpace> 
<GNSNameData> 
<ltem> 

<Name> 

GrooveldentityURL 
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</Name> 
<Value> 

GrooveldentityURL_value_1 

<A/alue> 
</ltem> 
<ltem> 

<Name> 

GrooveClientDeviceURL 

</Name> 
<Value> 

GrooveClientDeviceURL_value_1 
<A/alue> 
</ltem> 
<ltem> 

<Name> 

GrooveClientRelayURL 

</Name> 

<Value> 

GrooveClientRelayURL_value_1 

<A/alue> 
</ltem> 
</GNSNameData> 
</UserName> 



</AddGNSNames> 
<RemoveGNSNames> 
<UserName> 

<GNSName> 

Username2 
</GNSName> 
<GNSNameSpace> 

SOAP 
</GNSNameSpace> 

<RenewKey> 

067fc9caea8d44b68f18ebb6e9c76acf 

</RenewKey> 
</UserName> 
</RemoveGNSNames> 
</GNSRequests> 

[124] Registration in the local name service is performed by a registration utility 
that reads the XML file and creates or appends registration data to an XML file in the 
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collaborative system data directory or a subdirectory of the collaborative system data 
directory. This latter XML file is used for name resolution. 

[125] Name service registration is performed by using the registration utility to 
serialize the XML file containing the registration request and send the resulting SOAP 
message to the name service. The registration utility de-serializes the response from 
the name service and prints a message describing the status of the registration request. 

[126] As discussed above, complete SOAP envelopes are sent from the 
illustrative server to the collaborative client, through its queue. However, since the 
collaborative client must support these SOAP calls as well, it can also handle SOAP 
requests made directly from SOAP clients as well using the same message format. 

[127] A software implementation of the above-described embodiment may 
comprise a series of computer instructions either fixed on a tangible medium, such as a 
computer readable media, for example, a diskette, a CD-ROM, a ROM memory, or a 
fixed disk, or transmittable to a computer system, via a modem or other interface dev.ce 
over a medium. The medium either can be a tangible medium, including but not l.m.ted 
to optical or analog communications lines, or may be implemented with wireless 
techniques, including but not limited to microwave, infrared or other transmission 
techniques. It may also be the Internet. The series of computer instructions embod.es 
all or part of the functionality previously described herein with respect to the invent.on. 
Those skilled in the art will appreciate that such computer instructions can be written in 
a number of programming languages for use with many computer architectures or 
operating systems. Further, such instructions may be stored using any memory 
technology, present or future, including, but not limited to, semiconductor, magnetic, 
optical or other memory devices, or transmitted using any communications technology, 
present or future, including but not limited to optical, infrared, microwave, or other 
transmission technologies. It is contemplated that such a computer program product 
may be distributed as a removable media with accompanying printed or electronic 
documentation, e.g., shrink wrapped software, pre-loaded with a computer system, e.g., 
on system ROM or fixed disk, or distributed from a server or electronic bulletin board 
over a network, e.g., the Internet or World Wide Web. 
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[128] Although an exemplary embodiment of the invention has been disclosed, it 
will be apparent to those skilled in the art that various changes and modifications can be 
made which will achieve some of the advantages of the invention without departing from 
the spirit and scope of the invention. For example, it will be obvious to those reasonably 
skilled in the art that, in other implementations, protocols and translations different from 
those shown may be performed. Other aspects, such as the specific process flow and 
the order of the illustrated steps, as well as other modifications to the inventive concept 
are intendedto be covered by the appended claims. 

[129] What is claimed is: 
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